Scalable Vector Graphics (SVG) is an XML-based language for representation of static and dynamic vector graphics. SVG is vector based which means that content is not made for certain screen resolutions but can easily be scaled. SVG is standardized by the World Wide Web Consortium (W3C). The mobile profile of SVG Version 1.1 was adopted by 3GPP Release 5 and is today supported by roughly 100 million mobile handsets.
SVG Tiny 1.2 is a more powerful version of SVG that is specifically designed for mobile devices, which is more thoroughly described in “Scalable Vector Graphics (SVG) Tiny 1.2 Specification”—W3C Candidate Recommendation, 10 Aug. 2006”. This specification is currently a W3C candidate recommendation which has been adopted by 3GPP Release 6. Support for a variety of new multimedia features, comprising full control of audio and video, is included along with micro DOM (uDOM) and scripting <uDOM>.
In addition to being a media type for vector graphics, SVG can also be used as a scene description language, where a scene can be composed temporarily, as well as spatially. In fact, SVG Tiny 1.2 is the base scene description format for the 3GPP work item in Dynamic and Interactive Multimedia Scenes (DIMS), as well as for the OMA work item on Rich-Media Environment (RME). More information on the present standardizations of DIMS can be found in ″3GPP TS 26.142 V7.1.0 (2007-09): “3.sup.rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Dynamic and Interactive Multimedia Scenes”.
FIG. 1a refers to a plane SVG, defined as a large document, carrying an SVG scene, here represented by a number of (0-k) SVG elements, E, according to the prior art. The whole scene typically has to be completely downloaded before rendering. In plain SVG there is, thus, only one single timeline, starting at 0, making global and local seeking identical.
DIMS (RME) content, as opposed to plane SVG content, can be split into base scenes and updates of these scenes. The format of these updates is LASeR commands.
An example of DIMS content according to the prior art is illustrated with FIG. 1b. A sequence of base scenes and updates can be streamed, using the Real-time Transport Protocol (RTP), or stored in a track of a 3GP file. A rendered SVG document consists of a number of units, starting with a base scene S, which will typically be updated with smaller scene updates, U.
Each unit in a DIMS Stream has a media time. The media time is often calculated using an offset from the first unit, using transport level timestamps. This is also referred to as global time 100 in this document, as it is continuous for the entire DIMS stream. SVG also has an internal document time, 101. The internal document, time is reset to zero for each new SVG document, 102,103 in the stream, and is therefore also referred to as a local time in the respective document. The global timeline will most probably not have the same rate as the local timelines, which typically may have a rate of 1 Hz.
Redundant scenes are redundant random access points (RAP's) that are handled-differently compared to non-redundant scenes as they are used to replace a scene and a number of updates when tuning in. The document time shall start at the same value as for the other users whom haven't tuned in on the redundant scene. It is therefore necessary to move the scene time forward, from the initial time of 0, to the tune-in time.
Currently, it has not been defined when to move the scene time forward in DIMS. The LASeR proposal moves the scene time forward after the scene has completely loaded. The MORE proposal is unspecific in this area, but the alternative, proposed under the MORE flag, moves the scene time forward on initial loading of the document.
Prior art solutions do not enable seeking in the global time of a DIMS stream from the markup, i.e. it is not possible to create “seek” buttons or seek instructions as was possible with plain SVG, having only one single timeline.
One problem raised when using the setCurrentTime method, defined in the SVG uDOM, for adjusting the time of an SVG document is that the SVG document time is changed, while the media time, or global time level remains unchanged, creating a mismatch between this new document time and the media time. Resynchronization in this case is performed in the same way as for any other synchronization, e.g. from disruption in the media transport. It is not defined whether one shall pause one of the elements, or seek forward in the other. Resynchronization can therefore result in the scene time simply being returned to its value before the seek, regaining synchronization but undoing the time change.
Another problem with prior art solutions is that there is no way of seeking over document borders. A DIMS stream may, and probably will, contain a number of non redundant scenes, i.e. SVG documents. Each such document has a separate timeline which begins with time instance zero.
Yet another problem with known technique is that it is not possible to choose the global time as synchronization base for synchronization, i.e. to force other timelines to synchronize to the global time. This can also be referred to as defining the Global Time as being the SyncMaster. This makes it impossible to create a stream which is defined to have its playback based entirely on transport level timestamps.